In common graphics APIs (e.g., OpenGL and D3D), shaded fragment color values may be blended with color values that are stored in a frame buffer. After a blend operation, the blended color value is written into the frame buffer. The blend equation for each color component has the form:Dst_new=SrcFact*Src<operation>DstFact*Dst, where                Src=the shaded fragment color value;        Dst=the current color value stored in the frame buffer;        SrcFact=coefficient that can be a source or destination alpha or color value, a constant, zero, one, etc.;        DstFact=coefficient that can be a source or destination alpha or color value, a constant, zero, one, etc.;        <operation>=blending operation (e.g., add, subtract, reverse subtract, min, max, etc.); and        Dst_new=the blended color value.        
Depending on the blend operation and the Src values, some color values may not change as the result of blending. For example, when using the standard alpha blend operation Dst_new=(SrcAlpha*Src+(1−SrcAlpha)*Dst), if SrcAlpha=0.0, the Dst_new value will equal Dst. It is common for a significant number of pixels to have SrcAlpha=0.0, particularly when rendering scenes with textured transparency. Similarly, it is also common for the Dst value to be unneeded. For example, if SrcAlpha=1.0, the Dst value does not need to be read.
Some graphics processing units (GPUs) implement blend optimizations to detect cases described above and kill fragments that will not cause a color update (e.g., when SrcAlpha=0.0) or suppress destination reads (e.g., when SrcAlpha=1.0). These blend optimizations were typically done for fixed-point data (e.g. 8-bit-per-component A8R8G8B8 color format), which have no representation for numbers outside the range [0.0, 1.0].
Recent GPUs support floating-point render target formats. Floating-point formats make blend optimizations difficult because of the presence of special values, such as −Zero, Inf, NaN, and denorms, and the requirement to handle special values in accordance with the IEEE standard for binary floating-point arithmetic (IEEE Standard 754) or similar standards mandated by the API (e.g. Microsoft Windows Graphics Foundation or DX10). For example, IEEE Standard 754 prescribes that 0*Inf must equal NaN and −0+0 must equal −0. Microsoft's DX10 prescribes that fp32 denorms must be flushed to zero when operated upon. However, if the blend optimizations described above are carried out in the presence of special values, these rules may be violated. The following example illustrates how the fp32 denorm flushing rule may be violated in the case where SrcAlpha=0.0 and Dst=denorm:                Without optimization: Dst_new=0.0*Src+1.0*Dst=0.0+1.0*denorm=0.0 (since denorms must flush to zero when operated upon).        With optimization: Dst_new=denorm.        
The following example illustrates how the 0*Inf rule may be violated in the case where SrcAlpha=1.0, Src=0.5 and Dst=Int                Without optimization: Dst_new=1.0*Src+0.0*Dst=0.5+0.0*Inf=NaN        With optimization: Dst_new=0.5        
Pixel shaders typically do not generate special values. When this is true, the blend optimizations performed for fixed point buffers could also be applied to floating-point buffers. However, since pixel shaders are arbitrary programs written by a user, it is difficult or impossible to guarantee that a given shader program will never generate a special value. Therefore, what is needed is a way of allowing blend optimizations in cases in which special values are not present, and properly handling those cases in which special values are present.